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[57] ABSTRACT 

A database interface and associated communication 
program are installed in each node in a communication 
network. The database interface provides a translation 
from the record format of the database and a standard- 
ized format for transmission to other nodes thus provid- 
ing translation between the formats of the different 
databases formats as records are transmitted between 
the databases on different nodes. The communication 
program transmits records that have been translated to 
the standardized format to nodes which contain corre- 
sponding records maintaining current records at each 
node. A node having a corresponding node can assign 
an owner. Assigning an owner causes the record to be 
sent to the database that is associated with the new 
owner. The owner has the responsibility for acting on 
the record. The originator of the record is also identi- 
fied. 

15 Claims, 6 Drawing Sheets 
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updates corresponding records at different databases 

DATABASE COMMUNICATION SYSTEM THAT with a minimum of burden on the users. 

PROVIDES AUTOMATIC FORMAT MfWW ov „ rtXf 

TRANSLATION AND TRANSMIS SION OP SUMMARY OF THE INVENTION 

RECORDS WHEN THE OWNER IDENTIFIED POR 5 It is an object of the present invention to provide an 

THE RECORD IS CHANGED improved communication system which addresses the 

above needs. 

BACKGROUND OF THE INVENTION j n accordance with an embodiment of the present 

This invention relates to a communication system in invention, a database interface and an associated com- 

which records are stored in independent databases and 10 munication program are installed at each node in a 

more specifically relates to communicating and updat- communication network. The database interface pro* 

ing corresponding records in the different independent vides a translation between the record format used at a 

databases. This invention is especially, but not exclu- database and a common standardized record format, 

sively , suited for intercompany database record sharing Thus, the database interface provides an inbound and 

such as between an equipment manufacturer and its 15 outbound translation of fields within a record in order 

customer. to provide compatibility with varying databases utilized 

A variety of communication networks exist which at different nodes. The standardized format is used by 

can transmit data files from an origination node (NODE the communication program to transmit record infor- 

O) to a destination node (NODE D). However, such a mation to the other nodes in the system. The communi- 

transmission may not achieve the goal of transferring 20 q^^qq program provides a means for transmitting re- 

the desired information from NODE O to NODE D in cords and updates of records to the nodes in the net- 

a form readily usable at NODE D. As an example, WO rk which need to maintain duplicate records. This 

assume that the information to be transmitted by co mmuni cation capability is substantially automated to 

NODE O is a record created in NODE O's indepen- nnnimize user demands, 
dent, local database. If the objective is to create a dupli- 25 

cate record in an independent, local database at NODE BRIEF DESCRIPTION OF THE DRAWING 

D, the received record can be direcUy ratered in FIG. 1 is a block diagram of a typical network which 

NODE D's database assuming both NODE O and ^0^*^ ^ embodiment of the present invention. 

NODE D ut^ the same da^ase and the same field fi G . 2 is a block diagram of a typical node in the 

formats. If the database at NODE D is not directly 30 nfttwork Q f pjQ j 

compatible with the record received from NODE O, a RG. 3 is a diagram which illustrates the relationship 
user at NODE D must manually ttanslate tiie received ^ 2^X 2^ commvmica 
record into a record in the local database format. It is ^S^^SSZ ^the present mvention. 
apparent that substantial inefficiencies exist where dif- IT;- !? ^ . „ * * Tt™ r 
ferent database formats are utilized. If the databases 35 « diagram which illustrates the mapping of 
utilized by NODE O and NODE D are controlled by a ^ ****** record into a standardized record for- 
independent companies, it is unlikely that each com- accordance with the present mvenUon. 
panywiU utilize the same database software. Even if the JB ™ G - 5 ^trates an embodiment of a communication 
companies did utilize the same database software, it is directory and file structure m accordance with an em- 
even more unlikely that each will have created a sub- 40 bo ^ c J* of present invention, 
stantially identical record format structures because of FIGS. 6 and 7 comprise a table that illustrates param- 
the different needs of each company. ctcTS utilized with each record in accordance with an 

It is possible to address this problem by utilizing a embodiment of the present invention, 

single database which can be accessed by a variety of F 10 - 8 » a flow diagram illustrating the transmission 

users. Such a solution has the disadvantage that all of 45 of a record from a node in accordance with an embodi- 

the users must agree to utilize the same format and mcnt ot% present invention. 

agree to a common set of rules regarding use and access FIG. 9 is a flow diagram illustrating receipt of a re- 

of the database. It is difficult to achieve agreement cord from another node in accordance with an embodi- 

among independent companies, or even different parts mcnt of the present invention. 

of the same company, because of their differing needs 50 DETAILED DESCRIPTION 

and objectives regarding database capabilities. w & 

Difficulties would still exist even if independent com- An exemplary application of the present invention 
parries utilized the same database software and record follows in order to appreciate the advantages of the 
format Although the common structure of the database present invention. Assume that a provider of telecom- 
records would enable records to be communicated over 55 munications equipment is coupled via a communication 
a conventional communication network and entered system to a plurality of independent users of its equip- 
into another dptftfra sfs difficulties exist in mamfaimng ment A trouble ticket, Le, a documented problem with 
duplicate records in different databases where the re- a failure of user owned equipment, is entered by a user 
cord can be updated by a user at any of the independent in an independent database controlled by the user. If the 
databases. Although it is possible to establish rules re- 60 trouble ticket relates to equipment supplied by the man- 
quiring that new and modified records be transmitted to ufacturer a copy of the trouble ticket is forwarded uti- 
others in the network, this places a substantial burden lizing the database interface and communication pro 
on each user in systems where it is desirable to maintain gram in accordance with an embodiment of the present 
duplicate records at different databases so that informa- invention to a corresponding field support organization 
tion can be locally accessed. 65 of the equipment provider. If this organization is able to 

Thus, there exists a need :for a communicati n system solve the problem, the duplicate ticket stored in a data- 

which provides flexibility by allowing individual nodes base of the support organization is modified indicating 

to utilize different databases and which automatically the solution or other relevant information relating to the 
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problem and transmitted to the originating user. If the with the database interface and permits the standardized 
organization is unable to solve the problem, it sends a record to be transmitted to a direct support node. A 
copy of the ticket to a different organization within the database interface at the support node translates the 
company with greater technical expertise and sends an standardized record into the appropriate format for the 
update of the same ticket back to the user so that the 5 independent database maintained by the support node, 
user is apprised of the status of the trouble ticket As- The support node acknowledges receipt of the record 
suming the higher level organization solves or other- to the user. Preferably, the direct support node gener- 
wise handles the problem, the higher level organization ates an electronic mail (e-mail) message to an assigned 
updates the trouble ticket and sends a copy of the up- support person, ad vising of the receipt of a problem 
dated trouble ticket back to the field support organiza- 10 ticket After the direct support person considers the 
tion which in turn sends the update to the end user. problem as documented by the user's record, the record 
Assuming the end user is satisfied with the solution to ^ typically be updated by the assigned support person 
the problem indicated on the updated trouble ticket, the to contain additional information and may request addi- 
ticket is updated and closed by the user with copies of tional information from the user relevant to the prob- 
the update being sent to the field support organization 15 lcm The record at the support node is updated in the 
and the higher level technical organization. Each orga- 8Up port node database and communicated to the origi- 
nization dealing with the trouble ticket is apprised of all m standardized format The database inter- 
updates to the trouble ticket by any involved party. face at the user node translates the received update from 
However, each of the parties (nodes in the communica- 8tajldardized format to the record format used at the 
tion system) are free to maintain an independent data- 20 ^ s loca] ^ ^ the system 
base so that each can mdependendy maintain statistics which addresses a trouble ticket maintains an updated 
and otherwise utilize the information according to the record reg ardless of the party making an update. Prefer- 
needs of each. aW ^ VC[SOn & th e fc notified by e-mail 
The illustrative embodiment of the present invention fJ^J^ ^o^ has been updatcd ^ ^ 
can be incorporated in a network utilized for problem 25 oUr%ntA uZ*+*Aw*a f^^iKi.^^n^i^^ Tfc,«T 
solving as cxphuned above. However, it will be appar- should be reviewed for possible additional action. Thus, 
ett^tho«SmX art^Ttiru^tTofAepret f u d a8S ^ n&d 8U PP°? P«™ are each guar- 
^ anteed of having access to the latest updated infonna- 

moTZ^ a^nimu^c^on'sVstem in which a * on concerrnng ^if^^JS 

~r in vn ^ an „ M *+ ™ maintain an independent database which can be tailored 

plurality of user nodes 10-20 are coupled to support 30 ai&IZZ* rtf ^ IMiM , mnA ntnMrf 

nodes 22 and 24 which are in turn coupled to central to m ff dlffcrcilt nccds of the user and the support 

support node 26. In the illustrative example, service pl ^!2 e ^ ... . , 

providers at nodes 22 and 24 are in a direct support level A FIG. 2 fllustrates a typical node ma system m accor- 
and have sufficient expertise to solve many of the prob- ^th the present invention. The node includes a 
lems posed by the users which they support Technical 35 nucioprocessor (MPU) 28, ^associated memory in- 
experts at node 26 provide corporate support to users eluding read-o^y memory (ROM) 30, random access 
for problems which the service providers at the direct memory (RAM) 32, and alternate memory storage 34 
support nodes cannot solve. The direct support nodes ***** M a or tape drive. Conventional input and 
are also connected to each other so that problem solv- output devices associated with MPU 28 include a key- 
ing expertise can be shared at the direct support level A 40 1)041(1 ^ a display terminal 38, and a communica- 
communication network 27 provides communication tion module 40 which enables communications between 
channels among the nodes. MPU 28 and a communication network 27. The node as 

This embodiment of the present invention is espe- ^ m KO. 2 can be used for any of the nodes as 
daily well suited for utilization in the illustrative ays- shown in FIG. 1. The communication network 27 may 
tern, especially when the equipment and/or software 45 comprise either the public switched telephone network 
supplied to users is complex. For example, users ma y sucn 88 °y modems or may comprise dedicated leased 
encounter difficulties in configuring the equipment to tin& between the users and connected nodes, 
properly interface with other peripheral equipment or F" 10 - 3 » a pictorial representation of the relationship 
in custo mizin g the operation of the equipment pursuant among software in accordance with the present inven- 
to a desired customer configuration. Help with such 50 tion. Local database software 46 receives input from the 
problems can normally be provided by the service pro- user and provides output to the user of stored records, 
viders at the support nodes. Another class of problems The database interface 44 translates the relevant fields 
which users may encounter deal with failures or errors m a record stored in the local database 46 into cone- 
in the basic operation of the equipment Some of these spending Gelds in a standardized record format Re- 
problems may be solved by personnel at the support 55 cords retrieved via interface 44 from the local database 
nodes, but other problems will require the greater tech- arc likewise translated for transmission by communica- 
nical expertise available from the r^hnlcfll experts at tion program 48 to. communication network 27 in the 
the central support node. standardized record format The standardized record 

In the illustrative example, a user documents a new format allows individual nodes to maintain different 
problem by entering appropriate information describing 60 local database software programs and define fields 
the equipment, nature of the problem, and other param- within records to meet the needs of the associated users 
eters utilizing the user's database. The user preferred of the node. The local database may consist of conven- 
format for storing information in the local independent ti nally available database software including flat file 
database is translated into a standardized record f rxnat and relati nal types. In order to minimize the overall 
by a database interface which is coupled to the local 65 communication network requirements in order to han- 
database. After the information is translated into the die the transmission of records, each of the nodes pref- 
standardized record format, a communication program erably utilizes a UNIX® operating system which ta- 
in accordance with the present invention interfaces herently contains communication support 
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FIG. 4 graphically illustrates how the database inter- standardized records are translated utilizing the data- 
face 44 interfaces with the local database 46. The stan- base interface 44 and then stored in the local database of 
dardized record format 50 is defined and stored in data- the node. To transmit a record stored in the local data- 
base interface 44. It is related to a local database record base 46 of the n de, the record is translated by the 
format 52 utilized by the local database 46. The stan- 5 database interface 44 and a copy of the standardized 
dardized record format 50 includes fields A-N which record placed in the corresponding subdirectory of the 
define different information parameters which can be destination node under OUT directory 64. The comma* 
communicated within the network shown in FIG. 1. nication program 60 periodically scans the files in the 
The local database record format 52 includes fields 1-99 OUT subdirectories and transmits the records via node 
which correspond to parameters determined by the 10 directory 56 to the destination node in communication 
operator of the node for possible storage in local data- network 27. After the transmission of the outbound 
base 46. The lines 54 which interconnect one field in record, a duplicate copy of the record is placed in a 
format 50 with one field in format 52 identify the trans- corresponding subdirectory under HOLD directory 66; 
lation or mapping which will occur when transferring the transmitted record in the subdirectory under OUT 
records 52 stored in local database 46 to other nodes in 15 directory 64 is deleted. If an acknowledgement is not 
the system. Each of the fields in record format 50 are received from the destination node within a predeter- 
preferably supported by a corresponding field in record mined time, an attempt to retransmit the record is re- 
format 52. The standardized record format 50 which is peated from the subdirectory under HOLD directory 
transmitted between nodes allows the independent data- 66. 

bases associated with each node to be able to share 20 FIGS. 6 and 7 illustrate the status of parameters asso- 

information with other nodes without requiring manual dated with a record relative to nodes 12, 22, and 26 of 

re-entry of the information at another database because FIG. 1 at time intervals TO, Tl, T2, T3, and T4. The 

of different record and field structures. state of the parameters shown in FIGS. 6 and 7 reflect 

In a preferred embodiment of the present invention, states at the end of each interval. Time TO corresponds 
one of the fields in standardized record format 50 identi- 25 to user node 12 creating a new record indicative of a 
fies if the record contains information which should be problem. A unique ticket number which also identifies 
interpreted by another node as a trouble ticket, Le. the originating node is assigned, Le. UN 12-1487. User 
typically a request for help by another node, and an- node 12 is also identified as the originator and owner of 
other field contains a description of the product or the trouble ticket; note the originator and owner rows 
manufacturer of the product associated with the prob- 30 in FIG. 6. The status of the trouble ticket is "open". In 
lcm. Each node preferably maintains in memory an the illustrative example the record was created and 
address map which identifies the support node to re- entered in the local database of node 12 without causing 
ceive a copy of the record dependent upon the equip- the record to be transmitted as a trouble ticket to direct 
ment manufacturer or product entered in the corre- support node 22. This indicates that records may be 
sponding record field. Thus, a user as illustrated in FIG. 35 opened and potentially closed by the originating user if 
1 does not have to provide an address of the direct the user determines a solution or otherwise decides that 
support node associated with the problem since this a trouble ticket is not to be generated. Thus the user's 
addressing will be accomplished automatically merely database can store records that are not trouble tickets, 
by the user initiating the trouble ticket Since the data- Assuming that node 12 now wishes to communicate 
base interface 44 is coupled to the communication pro- 40 the stored record as a trouble ticket for direct support 
gram 48 and monitors changes made to records in the node 22, a person at node 12 will load the stored inter- 
local database, a person entering data in local database mation from the local database 46 into database inter* 
46 need only change the ownership field in a trouble face 44 which includes the parameters as shown. The 
ticket in order to initiate transmission of the record to owner is changed from node 12 to node 22. The owner- 
the appropriate supporting node. It is contemplated that 45 ship parameter identifies the node from which help is 
the user can be coupled by the communication network sought The ownership of a given ticket may change 
to a variety of different support nodes which support from time to time depending upon the node from which 
different products. help is sought. User node 12 always remains the origina- 

FIG. 5 illustrates an exemplary directory structure, tor and the ticket number is never changed during the 

preferably associated with each node, in accordance 50 communication of records from node to node. This 

with the present invention, in order to facilitate commu- allows each trouble ticket to be assigned a sequential 

nications. Node directory 56 is the highest level direc- number by each node. At user node 12, the record is 

tory which interacts with communication network 27 to placed in node 22 of the OUT directory 64 for transmis- 

receive communications from the network which are sion to node 22 by the communication program. Upon 

addressed to the node and to transmit communications 55 receiving the record at node 22, it is placed under IN 

to another node in the network. Subdirectory BIN 58 directory 62 in the subdirectory corresponding to user 

contains the communication program 60 in accordance node 12. It is then transferred to the local database 46 of 

with the present invention. The communication pro- node 22. Thus, following the successful completion of 

gram 60 is explained, especially with regard to the flow the transmission, the identical record will exist at nodes 

diagram of FIGS. 8 and 9. Subdirectories 62, 64. and 66 60 12 and 22. 

each have symmetrical file structures. Each of these In this example, a service provider at node 22 is un- 

subdirectories contains a structure in which one alio- able to handle the problem associated with ticket UN 

cated subdirectory is maintained for each node in the 12-1487 and makes a determination that the ticket 

system. Each record received by node directory 56 is should be escalated to node 26 for additional help from 

placed under IN directory 62 and the subdirectory 65 the technical experts in problem solving. At node 22, 

which corresponds to the node which transmitted the the record is retrieved from the local database into the 

record. These files are periodically scanned by the data- database interface and the ownership changed from 

base interface 44 to check for received files. Received node 22 to node 26. Node 22 transmits the record at 
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time period T2 to node 26 in a similar manner explained utilized in which to check for multiple records to be 
as for the transmission from node 12 to node 22. In transmitted to the same destination. Step 78 represents 
addition, node 22 transmits the updated record to node that the rec rd is held waiting for an OUT transmission 
12 so that all nodes in the network will maintain identi- cycle to be started. At the end of the cycle, the record 
cal data for each ticket Each node in the network main- S is sent to the destination node, as indicated in step 80 
tains an address table which identifies the node from through communication network 27. In step 82 a copy 
which it received each trouble ticket and thus, permits of the transmitted record is placed in the destination 
a daisy-chain addressing by which updated rickets are node subdirectory under the HOLD directory. In deci- 
transmitted to the nodes which contain corresponding sion step 84 a determination is made if an acknowledge- 
stored records. Node 26 receives the record and stores 10 meat has been received from the destination node 
it in its local database. Preferably, upon receipt of each within a predetermined time If NO, control transfers to 
ticket at each node, a corresponding e-mail message is the beginning of step 78 to initiate a retransmission of 
generated to the person at the node associated with the record. Upon a YES determination by step 84, the 
handling such tickets. Thus, at the end of time interval record stored in the destination node subdirectory 
T2, nodes 12, 22, and 26 will each contain an identical 15 under HOLD is deleted since a retransmission will not 
copy of the ticket in each's database. be required. The transmission step terminates at END 

After considering the substance of the problem indi- 88. Thus, in accordance with the transmission accord- 
cated in the ticket, node 26 may make a determination ing to the present invention, a trouble ticket or record is 
of the cause of the problem and provide a solution. The transmitted to another node in standardized record 
documentation for the problem cause and the proposed 20 format based upon a corresponding local database re- 
solution will be included as updated information to the cord format 

ticket during time interval T3 and the status changed by FIG. 9 is a flow diagram illustrating steps in accor- 
node 26 from "open" to "solved". Node 26 initiates an dance with the present invention for receiving a record 
update transmission of the ticket to node 22 which in the transmitted from another node. Beginning at START 
daisy-chain manner retransmits the updated ticket back 25 90, the general node directory 56 receives a record 
to the originating node 12. It will also be noted that at addressed for the subject node as indicated in step 92. In 
time interval T3 the owner is changed from node 26 to step 94 the received record is put under the IN direc- 
user node 12, indicating that further disposition of the tory in the subdirectory of the node which transmitted 
problem ticket with the proposed solution rests with the the record. In step 96 the record is copied from the 
user at node IX 30 subdirectory under the IN directory to the database 

The user at node 12 considers the proposed solution interface 44 as a standardized record format. In step 95 
and accepts the solution proposed. During time interval an acknowledgement is sent to the node which transmit- 
T4, the user at node 12 changes the status of the mes- ted the record acknowledging its successful receipt In 
sage from solved to closed and transmits the updated step 98 the database 46 is updated by the database inter- 
record to node 22 which in daisy-chain manner trans- 35 race 44 translating the standardized record format and 
mhs the message to node 26. As illustrated in time T4, storing the record in the local database 46. A determina- 
each of the nodes communicating relative to the illustra- tion is made in step 102 of whether to transmit the re- 
tive trouble ticket will contain an identical record cord to another node. This decision is based upon the 
which indicates the status of the ticket is closed thereby destination contained with the record and the owner of 
ending further problem solving consideration of the 40 the record. For example, if an originating node identi- 
item by direct support providers at node 22 and the fies the owner as a node other than an intermediate node 
technical experts at central support node 26. The record which receives the record, the intermediate node will 
can be maintained in the local database of the respective recognize the need to transmit the record to the desig- 
nodes and utilized for other related problems should nated owner. Upon a YES determination by step 102, 
similar problems occur; the record can also be used for 45 control passes as indicated by transfer point "A" 104 
statistical data purposes. back to step 74 as shown in FIG. 8. The transmission 

FIG. 8 is a flow diagram illustrating steps in the trans- then continues as previously explained with regard to 
mission of a record to another node. Beginning at FIG. 8. A NO determination by step 102 indicates that 
START 68, the record to be transmitted is loaded from further transmission is not required and concludes the 
the local database to the standard record format of the 50 receipt of the record at END 106. 
database interface 44 as indicated by step 70. It will be In accordance with the present invention, a user 
understood by those skilled in the art that the record friendly communication system is provided in which all 
may also be directly entered by the user into the data- nodes in the system requiring access to a record main- 
base interface as well as being retrieved from storage in tains the record in a local database. Subsequent updates 
the local database* In step 72 the user requests transmis- 55 of the record by any node are automatically distributed 
slon of the record to another node such as by changing to the other nodes by utilizing a standardized record 
the ownership of the record. The address of the destina- format Thus, the present invention provides an en- 
don node is determined in step 74. In a preferred em- hanced communication system allowing independent 
bodiment of the present Invention, the destination is database flexibility while still providing the relevant 
determined from an originating node based upon a 60 nodes in the network with up-to-date records, 
stored table which correlates the address of the node Although an embodiment of the present invention has 
which services the equipment identified by the trouble been described and shown in the drawings, the scope of 
ticket Alternatively, the user at the originating node the invention is denned by the claims which follow, 
can directly enter the address of the node from which We claim: 

help is sought. Next, a copy of the trouble ticket is 6$ 1. A communication system comprising: 
placed in the destination node (DN) subdirectory under first and second nodes coupled to each other; 
the OUT directory. In accordance with the communi- first and second databases associated with said first 
cation program, a predetermined time interval can be and second nodes respectively, each store records, 
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said first database storing said records in a first field 
format and said second database storing said re- 
cords in a second field format which is different 
from said first field format; 

means at said first and second nodes for transmitting 5 
records having standardized format to and receiv- 
ing records having standardized format from the 
other of said first and second nodes, said standard- 
ized format being different from said first and sec- 
ond field formats; 10 

means at said first node for automatically translating 
a received standardized format record into said 
first field format record for storage in said first 
database and for automatically translating a first 
field format record stored in said first database into 15 
standardized format record for transmission to said 
second node; 

means for independently identifying an originator 
and an owner of each record, said translating and 
transmitting means acting to translate and transmit 20 
a first record contained in said first database associ- 
ated with said first node to said second database 
associated with said second node based upon entry 
in said first record of an owner associated with said 
second database, wherein records in said first data- 25 
base that do not identify an owner are not transmit- 
ted to said second database; 

said identifying means permitting the identified 
owner of a duplicate record stored at the second 
database and corresponding to said first record to 30 
be changed thereby changing responsibility for 
acting on the duplicate record and causing the 
duplicate record with changed ownership to be 
automatically transmitted to a database associated 
with the changed owner. 35 

2. The system according to claim 1 further compris- 
ing a plurality of other nodes in addition to said first and 
second nodes, said other nodes comprising: 

a database; 

means for transmitting standardized format records 40 
and receiving standardized format records and 

means for automatically translating a received stan- 
dardized format record into its field format record 
for storage in its database and for automatically 
translating a record stored in its database into a 45 
standardized format record for transmission to one 
of said first, second, and other nodes. 

3. The system according to claim 1 further compris- 
ing means associated with said second node for auto- 
matically transmitting a copy of an updated first record 50 
based on the original record from said second database 

to the first database containing the corresponding origi- 
nal record, said first database storing said updated first 
record. 

4. The system according to claim 1 further compris- 55 
ing means for labeling each record at its creation with a 
unique identification number which identifies all corre- 
sponding records in the communication system. 

5. A first node for use in a communications system 
having a plurality of nodes, said first node comprising: 60 

first database that stores records in a first field format; 

means for transmitting records having standardized 
format to and receiving records having standard- 
ized format from one f said nodes, said standard- 
ized format being different from said first field 65 
format; 

means for automatically translating a standardized 
format record into said first field format for storage 
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in said first database and f r automatically translat- 
ing a first field format record stored in said first 
database into a standardized format record for 
transmission to one of said nodes; 

means for independently identifying an originator 
and an owner of each record, said translating and 
transmitting means acting to translate and transmit 
a first record contained in said first database associ- 
ated with said first node to a second database asso- 
ciated with a second node based upon entry in said 
first record of an owner associated with said sec- 
ond database, wherein records in said first database 
that do not identify an owner are not transmitted to 
said second database; 

said identifying means permitting the identified 
owner of a duplicate record stored at the second 
database and corresponding to said first record to 
be changed thereby changing responsibility for 
acting on the duplicate record and causing the 
duplicate record with changed ownership to be 
automatically transmitted to a database associated 
with the changed owner. 

6. The node according to claim 5 further comprising 
means for automatically sending records stored in the 
first database that have been modified to other nodes 
which contain corresponding records thereby keeping 
corresponding records at other nodes updated. 

7. The node according to claim 5 further comprising 
means for labeling each record at its creation with a 
unique identification number which always identifies all 
corresponding records in other nodes in the communi- 
cation system. 

8. A method for handling records in a communica- 
tions system which includes at least first and second 
nodes having first and second databases, respectively, 
said first database storing records in a first field format 
and said second database storing records in a second 
field format which is different from said first field for- 
mat, said method comprising the steps of: 

transmitting records having a standardized format 
from said first node and receiving records having a 
standardized format at said first node from said 
second node, said standardized format being differ- 
ent from said first and second field formats; 

aut omaticall y translating a standardized format re- 
cord received by said first node into said first field 
format record for storage in said first database and 
for automatically translating a first field format 
record stored in said first database into a standard- 
ized format record for transmission to said second 
node; 

independently identifying an originator and an owner 
of each record, said translating and transmitting 
steps translating and transmitting a first record 
contained in said first database associated with said 
first node to said second database associated with 
said second node based upon entry in said first 
record of an owner associated with said second 
database, wherein records in said first database that 
do not identify an owner are not transmitted to said 
second database; 

said identifying step permitting the identified owner 
of a duplicate record stored at the second database 
and corresponding to said first record to be 
changed thereby changing responsibility for acting 
on the duplicate record and causing the duplicate 
record with changed ownership to be automati- 
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cally transmitted to a database associated with the 
changed owner. 

9. The method according to claim 8 farther compris- 
ing the step of automatically updating records stored in 
databases of other nodes upon a corresponding record 5 
being modified at one node in the communication sys- 
tem. 

10. The method according to claim 8 further compris- 
ing the step of labeling each record at its creation with 

a unique identification number which identifies all cor- 10 
responding records in other databases in the communi- 
cation system. 

11 The method according to claim 8 wherein said 
identifying step permits the owner of a corresponding 
set of records to be changed by any node which stores 
one of the corresponding records thereby allowing the 
responsibility for acting on the record to be changed. 

1Z A method for handling records by a node in a 
communications system having other nodes, said ^ 
method comprising the steps of: 

storing records using a first field format in a first 
database; 

transmitting records having a standardized format to 
and receiving records having a standardized format 2 s 
from said other nodes, said standardized format 
being different from said first field format; 

automatically translating a standardized format re- 
cord received from one of said other nodes into a 
first field format record and storing said translated 30 
record in said first database; 

translating a first field format record stored in said 
first database into standardized format record and 
transmitting said standardized record to at least one 
of said other nodes; 35 



independently identifying an riginator and an owner 
of each record, said translating and transmitting 
steps translating and transmitting a first record 
contained in said first database associated with said 
first node to said second database associated with 
said second node based upon entry in said first 
record of an owner associated with said second 
database, wherein records in said first database that 
do not identify an owner are not transmitted to said 
second database; 

said identifying step permitting the identified owner 
of a duplicate record stored at the second database 
and corresponding to said first record to be 
changed thereby changing responsibility for acting 
on the duplicate record and causing the duplicate 
record with changed ownership to be automati- 
cally transmitted to a database associated with the 
changed owner. 

13. The method according to claim 12 further com- 
prising the step of automatically sending records stored 
in the first database that have been modified by a user to 
other nodes, which contain corresponding records 
thereby keeping corresponding records at other nodes 
updated. 

14. The method according to claim 12 further com- 
prising the step of labeling each record at its creation 
with a unique identification number which identifies all 
corresponding records in other nodes in the communi- 
cation system. 

15. The method according to claim 12 wherein said 
identifying step permits (he owner of a corresponding 
set of records to be changed by a node which stores one 
of the corresponding records thereby allowing the re- 
sponsibility for acting on the record to be changed. 
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